home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Technotools
/
Technotools (Chestnut CD-ROM)(1993).ISO
/
lantools
/
odidoc
/
odidoc.txt
< prev
next >
Wrap
Text File
|
1990-09-28
|
72KB
|
2,398 lines
DOS ODI WORKSTATION
August 1990 Edition
Revision 1.0
Novell, Incorporated
122 East 1700 South
P.O. Box 5900
Provo, Utah 84606 USA
■ Copyright 1990 Novell, Inc. All rights reserved. No
part of this publication may be reproduced, photocopied,
stored on a retrieval system, or transmitted without the
express prior written consent of the publisher.
Novell Part # 100-000871-001
Disclaimer
Novell, Inc. makes no representations or warranties with respect to the
contents or use of this manual, and specifically disclaims any express or
implied warranties of merchantability or fitness for any particular
purpose. Further, Novell, Inc. reserves the right to revise this
publication and to make changes to its content, at any time, without
obligation to notify any person or entity of such revisions or changes.
Further, Novell, Inc. makes no representations or warranties with respect
to any NetWare software, and specifically disclaims any express or
implied warranties of merchantability or fitness for any particular
purpose. Further, Novell, Inc. reserves the right to make changes to any
and all parts of NetWare software, at any time, without obligation to
notify any person or entity of such changes.
FCC warning
Computing devices and peripherals manufactured by Novell generate,
use, and can radiate radio frequency energy, and if not installed and
used in accordance with the instructions in this manual, may cause
interference to radio communications. Such equipment has been tested
and found to comply with the limits for a Class A computing device
pursuant to Subpart J of Part 15 of FCC Rules, which are designed to
provide reasonable protection against radio interference when operated
in a commercial environment. Operation of this equipment in a
residential area is likely to cause interference, in which case the user---at
his own expense---will be required to take whatever measures are
necessary to correct the interference.
Some components may not have been manufactured by Novell, Inc. If
not, Novell has been advised by the manufacturer of the component that
the component has been tested and complies with the Class A computing
device limits as described above.
Copyright 1990 Novell, Inc. All rights reserved. No part of this
publication may be reproduced, photocopied, stored on a retrieval
system, or transmitted without the express prior written consent of the
publisher.
Novell, Incorporated
122 East 1700 South
Provo, Utah 84606 USA
August 1990 Edition
Manual Revision 1.0
For NetWare v3.1 and above
Novell Part # 100-000871-001
Table of Contents
How to Use This Manual ii
DOS ODI Workstation Installation 1
Prepare the workstations 4
Install the network board 5
Create the master workstation diskette 7
Create the workstation boot disk 11
Boot the workstation and log in
to the file server 12
NET.CFG Options 17
Link support 20
Protocol 21
Link driver drivername 23
Link driver LANSUP 30
Appendix A: Using the IBM Token-Ring
Source Routing Driver 31
Using the Source Routing Driver
with DOS ODI 33
Appendix B: System Messages 37
Trademarks 69
Index 71
How to Use This Manual
This manual explains how to set up and install a DOS ODI workstation.
The installation section tells you how to prepare the workstation and
create boot diskettes for use with DOS ODI.
The NET.CFG section contains configuration information for the
NET.CFG file. Use the information in this section if you are not using
the default options for your workstation.
Appendix A contains information on using the IBM Token-Ring Source
Routing Driver.
Appendix B contains system messages.
DOS ODI Workstation Installation
Novell's interconnectivity strategy for the 1990s, Open Data-Link
Interface (ODI), adds functionality to NetWare and network
computing environments by supporting multiple protocols and drivers.
ODI creates a ■logical network board■ to send different packet types
over one network board and wire.
You can benefit from ODI in the following ways:
You can expand your network by using multiple protocols (such as
IPX/SPX, AppleTalk, or TCP/IP as they become available) without
adding network boards to the workstation.
You can communicate with a variety of workstations, file servers, and
mainframe computers via different protocol stacks without rebooting
your workstation.
You can protect your investment because protocols send packets
through any LAN driver written to ODI specifications.
You can spend less time and money on support. With one LAN driver
supporting multiple protocols, you have fewer hardware components
to support.
You can use the NET.CFG file to configure the LAN driver for any
possible hardware configuration, instead of being limited by SHGEN
choices.
You can free up memory by using only the portions of IPX/SPX and
diagnostics that you need.
As new LAN drivers and protocol transports are released, they will be
available on NetWire.
Using DOS ODI workstation software
You can convert a standalone personal computer into a DOS ODI
network workstation by adding one or more network boards, cabling,
and the DOS ODI workstation software.
If you are using a third-party network board, DOS ODI will not
function unless you have a DOS ODI LAN driver for the board.
Check the documentation that came with your network board for
more information.
DOS ODI Workstation software can be stored on a diskette or on a
workstation's hard disk. Three sets of files allow workstations to
■talk■ to each other, to the file server, and to other third-party hosts.
The first file is LSL.COM, the Link Support Layer file. This file
enables the workstation to communicate over several protocols.
Next are the LAN driver files, such as NE2000.COM and NE2.COM.
Third are the protocol stack files, such as IPXODI.COM for NetWare
networks, that manage communications among the network stations.
In addition, you may need files specific to the networking product
you are using. For example, if you want to install an ODI
workstation on a NetWare network, you need the shell file
(NETx.COM) that redirects messages from DOS to the network.
This section documents how to install a DOS ODI workstation on a
NetWare network using the IPX protocol stack. To install a DOS ODI
workstation using another protocol stack or network, use these
instructions as an example. You will have to modify them to fit your
situation.
You will need to follow the basic procedures of loading the LSL.COM,
the ODI LAN drivers, a protocol stack, and then any other files
specific to your software.
Remote boot is not available for DOS ODI workstations with this
release.
What you will need
To install DOS ODI workstations, you need the following:
The DOS ODI Workstation Installation flow chart (Quick Path) to get
an overview of the process
A working copy of the DOS ODI WORKSTATION SERVICES diskette
Enough DOS system diskettes to make master workstation diskettes
and boot diskettes
A ■disk■ (formatted diskette or hard disk) for each workstation to
boot from
The DOS ODI Workstation Installation flow chart (Quick Path) is
found at the beginning of this manual.
Table of Contents
Task Page
Prepare the workstations 4
Install the network board 5
Create the master workstation
diskette 7
Create the workstation boot disk 11
Boot the workstation and log in
to the file server 12
Troubleshooting tips 13
Where to go from here 15
Prepare the workstations
Check the hardware and memory requirements.
Use any of the following computers as workstations:
IBM PC or compatible
IBM PC XT or compatible
IBM PC AT or compatible
IBM Personal System/2 (any model)
NetWare workstations have the following memory requirements:
Up to 80KB of memory to load the NetWare workstation files
At least 512KB of memory to run application programs and NetWare
menu utilities
If your workstations need more memory, install additional memory
boards available from your computer dealer. Consult the manuals
from your computer manufacturer for installing memory boards.
Record the hardware information for the workstation on the
Workstation Configuration Worksheet.
Set up your workstations.
Install all equipment for the workstation except the network board
and cabling.
Follow the hardware setup instructions in the Guide to Operations or
Quick Reference for each computer.
Boot each workstation with DOS.
Booting each workstation with DOS ensures that the station is
functional as a standalone computer.
When each workstation has booted successfully, turn it off and
continue with installation.
Install the network board
Make sure the network board conforms to your cabling topology (such
as RX-Net or Ethernet).
Select and set network board configurations.
Use the following guidelines.
Refer to the documentation that came with the network board to
select and set the board configuration.
Set the same configuration option on like boards for all your
workstations. This reduces the number of master diskettes you will
have to make.
Choose the default configuration (shown as option 0 in the network
board supplements) if no other devices are using the settings. (Many
network boards are factory set to the default.)
Make sure the configuration option of each board is unique from
those of other boards or hardware installed in the computer (network
boards, graphics and modem boards, etc.).
Record the network board configuration settings on the Workstation
Configuration Worksheet.
These settings can be helpful if you need to troubleshoot problems on
your network later.
Install the network board.
Make sure the workstation is turned off before installing
the board.
Create the master workstation diskette
The master workstation diskette is a copy of the files necessary to
boot one type of workstation. You will copy files from the DOSODI
subdirectory of the DOS ODI WORKSTATION SERVICES diskette to
the master workstation diskette.
Then you will make individual workstation boot diskettes by copying
the files from the master workstation diskette to the boot diskettes
and by customizing the boot diskettes.
Create system diskettes by using the DOS FORMAT command with
the /s parameter.
Format these diskettes using the correct version of DOS registered for
each workstation on the network.
Label the master workstation diskette.
Label the master workstation diskette with the name of the LAN
driver (such as ■Master Workstation NE2000■), and list the
configuration settings on the diskette.
Configure software files (such as DXMAID) that came with your
network board (optional).
If you received additional software with your network board (for
example, the DXMAID program for Token-Ring network boards), see
the
installation supplement or accompanying documentation for steps to
configure those files.
Copy the shell file you want from your NetWare diskette to the master
workstation diskette.
(The x in NETx.COM refers to the DOS version that runs on your
workstations.)
If you are using the extended or expanded memory shells, copy the
.SYS files from the diskettes that come with the extended or expanded
memory applications. Specify those files as device drivers in your
CONFIG.SYS file so that they will be loaded when the workstation
boots. For example,
DEVICE = HIMEM.SYS
Copy the workstation files from the DOSODI subdirectory of the DOS
ODI WORKSTATION SERVICES diskette to the master workstation
diskette.
The following files are required to communicate with a NetWare
server:
LSL.COM
The LAN driver for your network board (NE2000.COM, for example)
The protocol stack file (IPXODI.COM, for example)
NETx.COM
The LANSUP.COM driver is for Token-Ring networks using the IBM
LAN SUPPORT PROGRAM. The LANSUP.COM file can be used
with PC Network and with Token-Ring networks.
The following files are optional on the master workstation diskette:
Put the executable files you selected into an AUTOEXEC.BAT file on
the master workstation diskette.
Use a DOS text editor to create the AUTOEXEC.BAT file, and save it
to the master workstation diskette. It is important to load the files in
the following order: link support layer, LAN driver, protocol stack,
then the shell.
This is a sample AUTOEXEC.BAT file:
LSL
NE2000
IPXODI
NET3
See your DOS manual for ideas.
Create a CONFIG.SYS file on the master workstation diskette using a
DOS text editor (optional).
If you are using memory managers, you need a line in CONFIG.SYS to
specify the memory managers as devices. See your memory manager
documentation for details.
If you are using the IBM LAN SUPPORT PROGRAM, you must add
two to three device drivers to CONFIG.SYS. See your DOS manual
for details.
Create a NET.CFG file on the master workstation diskette (optional).
Usually, you do not need a NET.CFG file because the established
defaults are adequate for your network.
Test boot a workstation with the master workstation diskette.
Create the workstation boot disk
Copy the master workstation diskette files to each workstation boot
disk.
If you are copying files to diskette, use the DOS FORMAT command
with the /s parameter to make a system diskette.
Personalize the boot disk with executable files, and update the
AUTOEXEC.BAT file (optional).
If the owner of the bootable files wants any other commands executed
or programs loaded during the boot process, add those files to the boot
area, and make the appropriate changes to the AUTOEXEC.BAT file.
Label the workstation boot diskette (optional).
If you are using a boot diskette, label it with the LAN driver, the
configuration option, and the custom boot files included. This
prevents the boot diskette from being confused with other diskettes.
Record the boot file information.
This information is helpful for troubleshooting.
Repeat Steps 1 through 4 for each workstation.
Boot the workstation and log in to the file server
Boot the workstation.
Boot your workstation either of the following ways:
Insert the workstation boot diskette into drive A and turn the
workstation on.
Copy the boot diskette files to the workstation's root directory on the
hard disk, and reboot by pressing <Ctrl> <Alt> <Delete>
simultaneously.
Log in to the file server.
If your AUTOEXEC.BAT file does not contain login commands, type
F: <Enter>
LOGIN SUPERVISOR <Enter>
Troubleshooting tips
If you get the message ■A File Server could not be found,■ check to
see if
The network board is seated properly.
The cable is connected properly. (Run COMCHECK to verify the
connections.)
All cabling is terminated properly.
The workstation node address conflicts with any other node address.
If you want information about the drivers that are loaded, type a
question mark after the driver name.
For example
NE2000 ? <Enter>
or
LSL.COM ? <Enter>
or
IPXODI ? <Enter>
Remove parts of IPXODI.COM to save memory.
The IPXODI.COM file actually contains three parts:
IPX
SPX
Remote Diagnostics Responder
Since many applications do not need SPX or the Remote Diagnostics
Responder (required for third-party applications that gather
diagnostics information), some workstations can save memory by not
loading these parts of the IPXODI.COM file.
Some NetWare utilities, such as RCONSOLE and NVER,
require SPX and the Remote Diagnostics Responder to be
loaded.
Use the chart below to see how to load IPXODI.COM without the
other two parts of the file.
To unload ODI drivers from the workstation, unload them in reverse
order.
For example, if you work with a protocol that requires a different
shell or if you are working with two protocols that conflict when both
are running on the workstation, unload the first set of files (in
reverse order) before you load the next set.
Unload the workstation files as follows:
NET3 u <Enter>
IPXODI u <Enter>
NE2 u <Enter>
LSL u <Enter>
If you do not unload the files in reverse order, you get an error
message similar to this: FATAL: There is a TSR above the loaded
IPXODI.
Where to go from here
Notes
NET.CFG Options
The NET.CFG file contains the configuration information for the
workstation. It is a control file that contains section headings and the
currently defined options that deviate from the established defaults of
the regular workstation boot process.
Usually, you do not need a NET.CFG file because the established
defaults are adequate for your network.
Use any DOS text editor to create the file. Specify only options that will
change from the defaults.
If you have installed a dedicated IPX workstation, you are probably
familiar with the SHELL.CFG file that also contains network
configuration information. The information in SHELL.CFG is now
migrating to the more versatile NET.CFG file. Any options from the
SHELL.CFG file can be addressed in the NET.CFG file.
Use the chart below to determine whether to use both .CFG files or to
combine them into NET.CFG.
If you place any SHELL.CFG options in the NET.CFG file, they will be
ignored.
See your NetWare manual for SHELL.CFG options.
Conventions
The NET.CFG file is left-justified for main section headings and
indented (with either a space or a tab) under each heading.
Keywords and main headings are not case sensitive.
Below are the most common section headings in the NET.CFG file:
Link support
Protocol (protocol_name)
Link driver (drivername)
The heading must precede the options you want to include in that
section. End each line with a hard return.
Write all numbers in decimal notation except where noted otherwise.
Precede comments by a pound (#) sign.
Sample NET.CFG file
LINK DRIVER NE1000
# Change the interrupt (IRQ) to 5.
INT 5
# Change the DMA channel to 3.
DMA 3
# Change the base memory address (hex) to an
# absolute value of C0000.
MEM C0000
# Change the port to 300 (hex)
PORT 300
The following chart lists the options unique to the NET.CFG file. Main
section headings are in white print and flush with the left margin. The
options are listed under each heading and indented.
Following the chart is a brief explanation of each option's function and
some possible reasons for changing the setting.
If you are using third-party protocol or LAN drivers, see their
documentation for any additional parameters.
In the following definitions, these conventions are used:
[ ] An optional element
number A decimal number
hex A hexadecimal number
Link Support
BUFFERS communication_number [size]
This option configures the number of receive buffers and their size on
the network.
The number of communication buffers must be large enough to hold all
media headers and the maximum data size.
Default: 0
The IPXODI protocol stack does not use the Link Support Layer
communication buffers.
Refer to the documentation for the third-party protocol stack for
settings.
Buffer size is optional. The minimum size is 586. The total buffer space
must fit into approximately 59KB (number times buffer size).
Default: 1130
MEMPOOL number [k]
Some protocols use this option to configure the size of the memory pool
buffers that the Link Support Layer will maintain.
The IPXODI protocol stack does not use the MEMPOOL buffers.
Refer to the documentation for the third-party protocol stack for
settings.
The k notation means multiply by 1024.
Protocol "protocol_name"
BIND name
Usually IPXODI binds to the first network board it finds. This option
limits the search to the network board you specify.
Replace name with one of the following LAN driver names:
TRXNET (for Novell RX-Net and Turbo RX-Net)
NE2 (for Novell Ethernet NE/2)
NE2-32 (for Novell Ethernet NE/2-32)
NE1000 (for Novell Ethernet NE1000)
NE2000 (for Novell Ethernet NE2000)
LANSUP (for the IBM LAN Support program only)
3C503 (for 3Com EtherLink Series 503)
3C523 (for 3Com EtherLink/MC 3C523)
In a DOS environment, you can bind IPXODI.COM to only one network
board.
For example, if you have an NE1000 board in slot 0 and an NE2000
board in slot 1 in your workstation, IPXODI binds to the NE1000 board
if you specify nothing in the NET.CFG file. However, if you place
BIND NE2000 in the NET.CFG file, IPXODI binds to the NE2000 board.
DEFAULT name
This option requests the protocol stack to bind with the LAN driver
(MLID) and configures the protocol to a default stack.
IPXODI ignores this parameter.
Replace name with one of the LAN driver names listed for BIND on the
previous page.
PRESCAN name
This option requests the protocol stack to bind with the LAN driver
(MLID) named and configures the protocol to a default prescan stack.
IPXODI ignores this parameter.
Replace name with one of the LAN driver names listed for BIND on the
previous page.
SESSIONS number
This option configures the number of sessions that the protocol stack
will be required to maintain at one time.
See the third-party protocol documentation for the minimum and
maximum values.
IPXODI ignores this parameter.
Link Driver drivername
To use this heading, replace drivername with the name of the driver you
are using; then use one or more of the following options. The name is
typically the LAN driver's filename.
You can use these options with as many different network boards as you
have, but you must have a separate Link Driver drivername heading for
each board.
Replace drivername with one of the following driver names:
TRXNET (for Novell RX-Net and Turbo RX-Net)
NE2 (for Novell Ethernet NE/2)
NE2-32 (for Novell Ethernet NE/2-32)
NE1000 (for Novell Ethernet NE1000)
NE2000 (for Novell Ethernet NE2000)
LANSUP (for the IBM LAN Support program only)
3C503 (for 3Com EtherLink Series 503)
3C523 (for 3Com EtherLink/MC 3C523)
Place both hardware commands and software commands under the Link
driver heading.
Hardware commands
DMA [#1 | #2] channel_number
This option specifies the hardware setting of the network board used in
the workstation. This option allows one of two DMA channels to be
configured.
Enter the channel number to be used. (The driver for the board will
automatically select its default channel number.)
If you do not specify which of the two configurable DMA channels (#1
or #2) to configure, this option defaults to the first configurable channel
(#1).
You do not need to include the #1 option if you are using only the
default option. For example, if the first configurable DMA channel on
your board uses DMA channel 3, place the following lines in your
NET.CFG file:
Link Driver name
DMA 3
For example, if the first configurable DMA channel on your board will
use channel 3 and the second configurable channel will use channel 4,
place the following lines in your NET.CFG file:
Link Driver name
DMA 3
DMA #2 4
Notice that the second DMA channel requires you to use the pound sign
(#).
INT [#1 | #2] interrupt_request_number
This option specifies which interrupts the network board uses. Use the
interrupt request number set on the board.
If you do not specify which interrupt line (#1 or #2) to configure, this
option uses the default, which is the first configurable interrupt line
(#1).
Do not include the #1 option if you are using only the default option.
For example, if the first configurable interrupt line on your board will
use IRQ 2, place the following lines in your NET.CFG file:
Link Driver name
Int 2
If your board can use two configurable interrupt lines and you want to
use both of them or only the second one, you must specify the interrupt
line (#1 or #2) to configure.
For example, if the first configurable interrupt line on your board will
use IRQ 2 and the second will use IRQ 3, place the following lines in
your NET.CFG file:
Link Driver name
Int 2
Int #2 3
The second DMA channel requires you to use the pound sign (#).
MEM [#1 | #2] hex_starting_address [hex_length]
This option specifies a memory range to be used by the network board.
Use the hexadecimal physical (absolute) address of the memory used by
the board. (This starting address must match the starting address
configured on the board.)
Enter the length (in hexadecimal paragraphs) of the memory address
range used by the board. A paragraph is normally 16 bytes.
For example, to address a board from D0000 to D4000 (bytes), the
starting address is D0000 and the range is 400 (paragraphs in 16KB
decimal length). In this case, place the following lines in your NET.CFG
file:
Link Driver name
Mem D0000
Usually, the length is not needed.
PORT [#1 | #2] hex_starting_address hex_number_of_ports
Use this option to specify the starting port and number of ports in the
range.
Use the starting hexadecimal I/O port number.
Use the hexadecimal number of ports in the range. If your network
board can use two ranges and you want to use either the second range or
both ranges, you must specify which range (#1 or #2) to use.
All values must be written in hexadecimal notation.
For example, suppose you want to specify the starting port and the
number of ports in the first range on your board. The starting I/O port
is 300; 16 ports are in the first range. Place the following lines in the
NET.CFG file:
Link Driver name
Port 300
The number of ports is optional.
NODE ADDRESS hex_address
This option overrides any hard-coded node address in the network board,
if the hardware allows it.
Use the hexadecimal address number.
Changing the node address on a board can create conflicts with
other network boards. Stay with the hard-coded node address
whenever possible.
The example below shows how to change the node address on a 3C523
board:
Link Driver 3C523
Node Address 12D43
PS/2 SLOT number
Use this option if you want to access two separate Ethernet backbones.
Use the number of the slot into which you inserted the board. The slot
number is found on the back of the computer. The LAN driver will use
the board in this slot.
For example, if you are using two NE/2 boards in the same workstation
and you insert one board into slot 1 and the other into slot 2, place the
following lines in your NET.CFG file:
Link Driver NE2
Link Driver NE2
PS/2 Slot 2
Then place the following lines in your AUTOEXEC.BAT file:
LSL
NE2
NE2
PS/2 SLOT ?
Use this option if you have inserted only one of the same kind of
network board in the workstation.
This option signals the LAN driver to scan for its board.
Software commands
FRAME frame_type
This option specifies the frame type that is used with the network board.
Use this option with boards that support more than one frame type.
For example, to specify an Ethernet board using the Ethernet II frame
type, place the following line in the NET.CFG file beneath the heading
for that driver:
Frame ETHERNET_II
Usually, Ethernet LAN drivers default to Ethernet_802.3; Token-Ring
LAN drivers default to Token-Ring.
Drivers that support more than one frame type (such as Ethernet) allow
multiple "frame" commands.
LOOK AHEAD SIZE number
This option specifies the number of bytes in the packet that the LAN
driver will send to the Link Support Layer to determine how to route the
packet. The range is 0 to 128 bytes depending on the protocol. See the
protocol documentation for the recommended size.
If two or more protocols are using a LAN driver, select the highest value
for the look-ahead size.
Default: 18 bytes
PROTOCOL name hex_protocol_ID frame_type
This option enables new protocols to be handled by existing LAN
drivers.
Replace name with the name of the new protocol.
Use the hexadecimal protocol ID number.
Replace frame_type with the frame type that the new protocol ID
applies to.
For example, if you attach a new protocol (XYZ) to your NE2-32
network board, the NET.CFG file could look similar to the following:
Link Driver NE2-32
Frame ETHERNET_SNAP
Protocol XYZ 904A ETHERNET_SNAP
SEND RETRIES number
This option specifies the maximum number of times the network board
driver will try to resend a packet following a communications error.
Use the number of times you want the driver to try resending the packet.
The default value is determined by the driver.
Link Driver LANSUP
The options below are unique to the LANSUP driver.
SAPS number
If you use the LANSUP driver with a network board, you must specify
the number of Service Access Points (SAPs) needed. Set the option to
allow for all applications using the IBM LAN Support Program. The
maximum value depends on the type of board used.
Default: 1
LINK STATIONS number
If you use the LANSUP driver with a network board, you must specify
the number of link stations needed. Set the option to allow for all
applications using the IBM LAN Support Program. The maximum value
depends on the type of board used.
Default: 1
Appendix A: Using the IBM Token-Ring Source Routing Driver
This appendix explains the use of the IBM Token-Ring Source Routing
Driver.
The IBM Token-Ring Source Routing Driver enables communication
across IBM Token-Ring network bridges. Any type of protocol stack can
use this DOS ODI feature to communicate across IBM Token-Ring
network bridges.
All nodes that need to communicate across a source route bridge must be
running the IBM Token-Ring Source Routing Driver.
For more information on using source routing, see the IBM Token-Ring
Network Architecture Reference manual.
The following figure shows an example network configuration using
IBM source routing bridges.
Figure A.1A network configuration using IBM source routing bridges
Using the Source Routing Driver with DOS ODI
To install source routing on workstations, complete the following steps.
Create a boot disk according to the instructions on page 11 of this
manual.
Copy the ROUTE.COM file from the DOS/ODI WORKSTATION
SERVICES diskette to the boot disk.
If you are creating an AUTOEXEC.BAT file for a DOS ODI
workstation, the command to load ROUTE.COM should be added after
LANSUP.COM but before the protocol stack you are using.
Set the parameters for ROUTE.COM. See "Additional Information" on
the next page for the parameters that ROUTE.COM can be loaded with.
Add the parameter in the AUTOEXEC.BAT file.
The default parameters for ROUTE.COM can be used with most network
communications.
Additional Information
The following parameters can be entered when ROUTE.COM is first
loaded.
BOARD = number MBR
CLEAR NODES = number
DEF REMOVE = number
GBR
The parameters can also be changed by loading ROUTE.COM a second
time. For on-line help, type
ROUTE ? <Enter>
Most of the parameters have default values that should work with simple
configurations for IBM bridges. If you have installed parallel IBM
bridges, you can change some of the parameters to reduce traffic on
some of the paths. Each parameter is described below.
BOARD = number
Use this parameter to specify a board number for the Token-Ring
network board.
If this parameter is not specified, the default of 01 is used.
If you have loaded more than one LAN driver in the workstation, the
board number is determined by the order in which the LAN drivers are
loaded (the first board is 1). See your AUTOEXEC.BAT file for the
order you have specified.
CLEAR
Use this parameter to manually clear the Source Routing table and force
a dynamic rebuilding of the table by sending a default frame to each
node in the network. Use this parameter when an IBM bridge on the
network has gone down and an alternate route is available.
DEF
Use this parameter to prevent frames that have unknown (DEFault)
destination addresses from being sent across Single Route IBM bridges.
If this parameter is specified, all frames that have addresses not in the
workstation's Source Routing table are forwarded as All Routes
Broadcast frames.
If this parameter is not specified, all frames that have addresses not in
the workstation's Source Routing table are forwarded as Single Route
Broadcast frames.
If ROUTE.COM has already been loaded with the DEF parameter,
reloading ROUTE.COM with this parameter broadcasts all subsequent
Single Route Broadcast frames as All Routes Broadcast frames.
GBR
Use this parameter to specify that all General BRoadcast frames are to
be sent as All Routes Broadcast frames.
If this parameter is not specified when ROUTE is loaded, all General
Broadcast frames are broadcasted as Single Route Broadcast frames.
If ROUTE has already been loaded with the GBR parameter, reloading
ROUTE with this parameter broadcasts all subsequent General Broadcast
frames as All Routes Broadcast frames.
MBR
Use this parameter to specify that all Multicast BRoadcast frames are to
be sent as All Routes Broadcast frames.
If the parameter is not specified when ROUTE is loaded, all Multicast
Broadcast frames are broadcast as Single Route Broadcast frames.
If ROUTE has already been loaded with the MBR parameter, reloading
ROUTE with this parameter broadcasts all subsequent Multicast
Broadcast frames as All Routes Broadcast frames.
NODES = number
Use this parameter to specify the number of table entries in the Source
Routing table. This parameter must be entered the first time
ROUTE.COM is loaded. The parameter cannot be changed by reloading
ROUTE.COM.
Replace number with a value from 8 to 255. The default is 16.
REMOVE = number
Use this parameter to remove a specified node address from the
workstation's Source Routing table. Use the parameter when a bridge
has gone down. Removing the node from the Source Routing table
forces the workstation to determine an alternate path.
Replace number with a 12-digit (6-byte) hexadecimal number. If fewer
than 9 digits are entered, ROUTE.COM prefixes the address with 4000h.
For example, REMOVE=2 is interpreted as REMOVE=400000000002.
Appendix B: System Messages
Connector is BNC.
Source: 3C503.COM
Explanation: The connector selected for the board is for Thin
Ethernet cabling.
Action: None
Connector is DIX.
Source: 3C503.COM
Explanation: The connector selected for the board is for Thick
Ethernet cabling.
Action: None.
FATAL: 3C503 -Card not found.
Source: 3C503.COM
Explanation: The 3C503.COM driver could not locate a 3C503
board at the specified hardware settings.
Action: Make sure that a 3C503 board is installed. Verify the
hardware jumper settings. If the settings do not match the
defaults, specify the settings in the NET.CFG file.
FATAL: 3C503 -Card will not initialize.
Source: 3C503.COM
Explanation: A hardware failure occurred.
Action: Check for possible hardware settings that conflict with
other installed boards.
FATAL: 3C503 -Interrupt is invalid (2,3,4,5,9 valid).
Source: 3C503.COM
Explanation: An invalid interrupt value was specified in the
NET.CFG file.
Action: Correct the ■INT number■ entry in the NET.CFG file;
then try again.
FATAL: 3C503 -I/O port does not match NICs jumper.
Source: 3C503.COM
Explanation: The specified base I/O port address (the driver
default or the value specified in the NET.CFG file) is different
from the address setting on the 3C503 board.
Action: Make sure that the value for the driver matches the value
set on the board; then try again.
FATAL: 3C503 -Memory does not match NICs jumper.
Source: 3C503.COM
Explanation: The specified base memory address (the driver
default or the value specified in the NET.CFG file) is different
from the address setting on the 3C503 board.
Action: Make sure that the value for the driver matches the value
set on the board; then try again.
FATAL: Board # <number> doesn't provide enough look ahead, IPX
needs 18 or more bytes.
Source: IPXODI
Explanation: IPX requires at least the first 18 bytes of incoming
packets for it to preview the packets properly.
Action: Increase the MLID look-ahead size by specifying ■LOOK
AHEAD SIZE 18■ in the NET.CFG file under the MLID main
section heading, as in the following example:
LINK DRIVER NE1000
LOOK AHEAD SIZE 18
FATAL: Board failed to initialize correctly.
Source: MLID
Explanation: The MLID could not initialize its board correctly.
A hardware failure usually prevents initialization.
Action: Refer to the MLID documentation for a description of
the error.
FATAL: Could not find a board that supports IPX (See PROTOCOL
keyword).
Source: IPXODI
Explanation: IPX could not find a board to bind with. For IPX
to bind, it must have a protocol ID registered with the Link
Support Layer. Most MLIDs will register an IPX Protocol ID by
default. However, if you have specified the PROTOCOL
keyword under an MLID's section heading in the NET.CFG file,
this error may be generated. When a protocol ID has been
specified for another protocol stack, the MLID does not register
a default protocol ID for IPX.
Action: If you want to use IPX, register a protocol ID for IPX
along with the other Protocol IDs you are registering.
FATAL: Could not find an enabled 3C523 adapter in any slot.
Source: 3C523.COM
Explanation: By default, the 3C523.COM driver scans the PS/2
slots to find the 3C523 board it should use. The driver starts
scanning at slot 1. The driver was unable to find a 3C523 in any
slot.
Action: Make sure that the 3C523 board is firmly seated in the
slot.
FATAL: Could not find an NE2 adapter in any slot.
Source: NE2.COM
Explanation: By default, the NE2.COM driver will scan the PS/2
slots to find the NE2 board it should use. The driver starts
scanning at slot 1. The driver could not find an NE2 in any slot.
Action: Make sure that the NE2 board is firmly seated in the
machine's slot.
FATAL: Could not find an NE2-32 adapter in any slot.
Source: NE2-32.COM
Explanation: By default, the NE2-32.COM driver will scan the
PS/2 slots to find the NE2-32 board it should use. The driver
starts scanning at slot 1. The driver was unable to find an NE2-
32 in any slot.
Action: Make sure that the NE2-32 board is firmly seated in the
slot.
FATAL: Could not find <name> MLID to unload.
Source: MLID
Explanation: A request was made to unload the MLID, but the
MLID is not loaded.
Action: None.
FATAL: Different IPX or a IPX interrupt has been hooked.
Source: IPXODI
Explanation: You tried to unload the IPX from memory, but the
IPX detected a condition that would not allow IPX to be removed
from memory safely. This can occur for two reasons:
The resident IPXODI and the IPXODI used to unload the resident
IPXODI are not the same version.
Another program has been loaded that has hooked one of
IPXODI's interrupt vectors. IPXODI uses the following interrupt
vectors: INT 08h, INT 2Fh, INT 64h, and INT 7Ah.
Action: Complete one of the following:
Use the same version of IPXODI to unload IPX as you used to
load.
Unload the program that has hooked to one or more IPX interrupt
vectors and then unload IPXODI.
FATAL: Different LSL or a LSL interrupt has been hooked.
Source: LSL
Explanation: You tried to unload the LSL from memory, but it
detected a condition that would not allow it to be removed safely.
This can occur for two reasons:
The resident LSL and the LSL used to unload the resident LSL
are not the same version.
Another program has been loaded that has hooked one of the
LSL's interrupt vectors. The LSL uses the following interrupt
vectors: INT 08h and INT 2Fh.
Action: Complete one of the following:
Use the same version to unload LSL as you used to load it.
Unload the program that has hooked to the LSL's interrupt
vectors before unloading the LSL.
FATAL: Direct Station 0 already in use by another application.
Source: LANSUP.COM
Explanation: The LANSUP.COM driver uses Direct Station 0.
Only one application running on the IBM LAN Support program
can use Direct Station 0.
Action: Unload the other application.
FATAL: Error initializing board.
Source: LANSUP.COM
Explanation: The LAN Support Program could not initialize the
network board.
Action: Check the installation of the LAN Support software.
FATAL: Error opening board.
Source: LANSUP.COM
Explanation: The LAN Support Program could not open the
network board.
Action: Check the installation of the LAN Support software.
FATAL: Error shutting down <name> MLID, unload operation aborted.
Source: MLID
Explanation: The MLID was attempting to remove the resident
MLID from memory. The MLID was unable to successfully shut
down the resident MLID. A hardware failure has probably
occurred.
Action: Run diagnostics on the network board and workstation.
Replace the faulty hardware.
FATAL: Failed to locate MLID Section Heading in NET.CFG file.
Source: MLID
Explanation: You tried to load the MLID again. Normally you
would do this so that you could use two or more boards in the
workstation. When two or more of the same type of network
boards are installed in the workstation, an associated MLID
section heading must be specified in the NET.CFG file. An entry
in the NET.CFG file for two boards would look similar to the
following:
#Allow the first one to use default values.
LINK DRIVER NE1000
#This section is for the second board.
LINK DRIVER NE1000
INT 4
PORT 320
Action: Add the commands for both MLID boards to the
NET.CFG file. Then reboot the workstation.
FATAL: IBM LAN Support Program has not been loaded.
Source: LANSUP.COM
Explanation: The LANSUP.COM driver requires that the IBM
LAN Support Program be loaded.
Action: Load the LAN Support Software and retry the operation.
Add lines similar to the following to the CONFIG.SYS file:
DEVICE=DXMA0MOD.SYS
DEVICE=DXMC0MOD.SYS
FATAL: Init586: Configure command failed.
Source: 3C523.COM
Explanation: A hardware failure has occurred.
Action: Install the 3C523 board in a different slot. If the driver
still fails to load, the 3C523 board is probably bad and should be
replaced.
FATAL: Init586: IA_Setup command failed.
Source: 3C523.COM
Explanation: A 3C523 hardware failure has occurred.
Action: Install the 3C523 in a different slot. If the driver still
fails to load, the 3C523 board is probably bad and should be
replaced.
FATAL: Init586: Initial communication with 82586 failed.
Source: 3C523.COM
Explanation: A hardware failure has occurred.
Action: Install the 3C523 board in a different slot. If the driver
still fails to load, the 3C523 board is probably bad and should be
replaced.
FATAL: Invalid base memory address - Must be C0000 or D0000.
Source: NE2-32.COM
Explanation: Because the NE2-32 board is a true 32-bit board, the
board has the option to have its base memory located above the
1MB real mode memory limit. Since DOS ODI is executing in real
mode, the NE2-32.COM driver cannot access the board's RAM
when it is located above the 1MB address range.
Action: Use the Reference diskette to change the board's base
memory setting to either C0000 or D0000.
FATAL: Invalid Ethernet node address specified.
Source: MLID
Explanation: You used the ■NODE■ option in the NET.CFG file
to override the node address on the network board. The number
specified was not a valid Ethernet node address. An Ethernet
address is 6 bytes in length. This error occurs if Bit 0 of the first
address byte is a 1. This bit must always be 0. For example, if
the first byte has the following address, an invalid Ethernet
address is generated.
First Byte
7 6 5 4 3 2 1 0
┌─┬─┬─┬─┬─┬─┬─┬─┐
│0│0│0│0│0│0│0│1│
└─┴─┴─┴─┴─┴─┴─┴─┘
This byte will produce node addresses in the 0100 0000 0000 to
01FF FFFF FFFF range, all of which will be invalid.
Action: Change the NET.CFG file so that a valid node address
is specified.
FATAL: Invalid parameter.
Source: IPXODI
Explanation: When you tried to load IPXODI, you specified an
invalid parameter on the command line. IPXODI was not loaded.
The only valid parameters are ? for information and U for
unload.
Action: Specify a valid parameter.
or
Source: LSL
Explanation: When you tried to load the LSL, you specified an
invalid parameter on the command line. The LSL was not loaded.
The only valid parameters are ? for help and U for unload.
Action: Specify a valid parameter.
or
Source: MLID
Explanation: When you tried to load the MLID, you specified an
invalid parameter on the command line. The MLID was not
loaded. The only valid parameters for MLID are ? for
information and U for unload.
Action: Specify a valid parameter.
FATAL: Invalid Token-Ring node address specified.
Source: MLID
Explanation: You used the ■NODE■ option in the NET.CFG file
to override the node address on the network board. The number
specified was not a valid Token-Ring node address. A Token-
Ring address is 6 bytes in length. This error will occur if Bit 7
of the first address byte is a 1. This bit should always be a 0.
For example, if the first byte has the following address, an
invalid Token-Ring address is generated.
First Byte
7 6 5 4 3 2 1 0
┌─┬─┬─┬─┬─┬─┬─┬─┐
│1│0│0│0│0│0│0│0│
└─┴─┴─┴─┴─┴─┴─┴─┘
This byte will produce node addresses in the 8000 0000 0000 to
8FFF FFFF FFFF range, all of which will be invalid.
Action: Change the NET.CFG file so that a valid node address
is specified.
FATAL: IPX already loaded.
Source: IPXODI
Explanation: IPX has already been loaded. It needs to be loaded
only once.
Action: None.
FATAL: IPX is already registered with the LSL.
Source: IPXODI
Explanation: IPX was not removed from the LSL's register when
it was unloaded. The system may be corrupted.
Action: Reboot the workstation.
FATAL: IPX is not loaded.
Source: IPXODI
Explanation: You tried to unload IPX, but IPX has not been
loaded.
Action: None.
FATAL: Loading MLID again requires configuration information in
NET.CFG.
Source: MLID
Explanation: You tried to load the MLID a second time.
Normally you would do this so that you could use two or more
boards in the workstation. When two or more of the same type of
network boards are installed in the workstation, an associated
MLID section heading must be specified in the NET.CFG file.
An entry in the NET.CFG file for two boards would look similar
to the following:
#Allow the first one to use default values.
LINK DRIVER NE1000
#This section is for the second board.
LINK DRIVER NE1000
INT 4
PORT 320
Action: Create a NET.CFG file and add the commands for both
MLID boards to the file. Then reboot the workstation.
FATAL: LSL already loaded.
Source: LSL
Explanation: The Link Support Layer has already been loaded.
The LSL can be loaded only once.
Action: None.
FATAL: LSL is not loaded.
Source: LSL
Explanation: You tried to unload the LSL, but it is not loaded.
Action: None.
FATAL: Multiplex interrupt 2Fh has no free slots.
Source: LSL
Explanation: LSL could not find a free slot for use with INT 2F
(Hex). When your computer is first booted, approximately 63
multiplex slots are available. All available slots are already being
used by applications.
Action: Unload an application that is using a INT 2F multiplex
interrupt; then load the LSL.
FATAL: NE1000 NIC command port failed to respond.
Source: NE1000.COM
Explanation: The NE1000 board has malfunctioned, is not
installed, or is not configured to the same port as selected for the
driver.
Action: Complete one or more of the following:
Make sure that an NE1000 board has been installed and
configured.
Make sure that the configuration for the NE1000 board matches
the configuration for the NE1000 driver. Configuration options
other than the defaults must be entered in the NET.CFG file.
Replace the board.
FATAL: NE1000 NIC RAM failure.
Source: NE1000.COM
Explanation: The NE1000 board's on-board memory has
malfunctioned.
Action: Replace the board.
FATAL: NE2 NIC command port failed to respond.
Source: NE2.COM
Explanation: The installed NE2 board has malfunctioned.
Action: Replace the board.
FATAL: NE2 NIC RAM failure.
Source: NE2.COM
Explanation: The NE2 board's installed on-board memory has
malfunctioned.
Action: Replace the board.
FATAL: NE2000 NIC command port failed to respond.
Source: NE2000.COM
Explanation: The NE2000 board has malfunctioned, is not
installed, or is not configured to the same port as selected for the
driver.
Action: Complete one or more of the following:
Make sure that an NE2000 board has been installed and
configured.
Make sure that the configuration for the NE2000 board matches
the configuration for the NE2000 driver. Configuration options
other than the defaults must be entered in the NET.CFG file.
Replace the board.
FATAL: NE2000 NIC is NOT supported in a 8-bit slot.
Source: NE2000.COM
Explanation: The NE2000 board is located in an 8-bit slot in the
machine. The NE2000.COM driver only supports the NE2000 in
a 16-bit AT bus slot.
Action: Place the NE2000 board in a 16-bit slot and try again.
FATAL: NE2000 NIC RAM failure.
Source: NE2000.COM
Explanation: The NE2000 board's on-board memory has
malfunctioned.
Action: Replace the board.
FATAL: NE2000 NIC was not found at specified hardware settings.
Source: NE2000.COM
Explanation: The NE2000.COM driver found a board at the
specified hardware settings, but the board is not an NE2000
board.
Action: Check the installed hardware.
FATAL: NE2-32 NIC command port failed to respond.
Source: NE2-32.COM
Explanation: The installed NE2-32 board has malfunctioned.
Action: Replace the board.
FATAL: NE2-32 NIC RAM failure.
Source: NE2-32.COM
Explanation: The installed NE2-32 board's on-board memory has
malfunctioned.
Action: Replace the board.
FATAL: No more room in the LSL for another protocol stack.
Source: IPXODI
Explanation: The maximum number of protocol stacks have been
registered with the Link Support Layer. The DOS ODI LSL can
support up to eight protocol stacks.
Action: Remove an existing protocol stack.
FATAL: RXNet command port failed to respond.
Source: TRXNET.COM
Explanation: The TRXNET.COM driver could not find an RX-
Net board in the workstation.
Action: Make sure that an RX-Net board is installed in the
workstation and that it is firmly seated. Make sure that the
values for the hardware settings in the driver (the default or the
values set in the NET.CFG file) match the values set on the board.
FATAL: RXNet RAM failure.
Source: TRXNET.COM
Explanation: The RX-Net board's RAM has failed the RAM test.
Action: Replace the board.
FATAL: Specified PS/2 slot contains an NE2 but it is not enabled.
Source: NE2.COM
Explanation: The located NE2 board was not enabled. The NE2
board has probably malfunctioned.
Action: Replace the board.
FATAL: Specified PS/2 slot contains an NE2-32 but it is not enabled.
Source: NE2-32.COM
Explanation: The located NE2-32 board was not enabled. The
NE2-32 board has probably malfunctioned.
Action: Replace the board.
FATAL: Specified PS/2 slot does not contain an enabled 3C523 adapter.
Source: 3C523.COM
Explanation: A ■PS/2 SLOT number■ option was specified in the
NET.CFG file. The specified slot does not contain a 3C523 board.
Note that slot numbers are 1 based and correspond to the slot
numbers on the back of the computer.
Action: Modify the NET.CFG so that the specified slot number
matches the slot that the board is installed in.
FATAL: Specified PS/2 slot does not contain an NE2 adapter.
Source: NE2.COM
Explanation: A ■PS/2 SLOT number■ option was specified in the
NET.CFG file. The specified slot does not contain an NE2 board.
Note that slot numbers are 1 based and correspond to the slot
numbers on the back of the computer.
Action: Modify the NET.CFG file to specify the correct slot
number.
FATAL: Specified PS/2 slot does not contain an NE2-32 adapter.
Source: NE2-32.COM
Explanation: A ■PS/2 SLOT number■ option was specified in the
NET.CFG file, but the specified slot does not contain an NE2-
32 board. Slot numbers are 1 based and correspond to the slot
numbers on the back of the computer.
Action: Modify the NET.CFG file to specify the correct slot
number.
FATAL: The LSL is not loaded.
Source: IPXODI
Explanation: IPX requires that the LSL be loaded first.
Action: Load LSL.COM; then load IPXODI.COM.
or
Source: MLID
Explanation: LSL must be loaded before an MLID can be loaded.
Action: Load LSL.COM; then load the MLID.
FATAL: There is a TSR above the loaded IPX.
Source: IPXODI
Explanation: You tried to unload IPX from memory, but IPX
detected another Terminate-and-Stay-Resident program loaded
above IPX. For IPX to unload safely, TSRs that were loaded
after it must be unloaded first.
Action: Either load the TSR before loading IPX or unload the
TSR before trying this operation.
FATAL: There is a TSR above the loaded LSL.
Source: LSL
Explanation: You tried to unload the LSL from memory, but the
LSL detected another Terminate-and-Stay-Resident program
loaded above the LSL. For the LSL to unload safely, TSRs that
have been loaded after it must be unloaded first.
Action: Either load the other TSR before loading the LSL or
unload the TSR before trying this operation.
FATAL: There is a TSR above the loaded <name> MLID.
Source: MLID
Explanation: You tried to unload the MLID from memory, but
the MLID detected another Terminate-and-Stay-Resident program
loaded above the MLID. For the MLID to safely unload, TSRs
that were loaded after it must be unloaded first.
Action: Either load the other TSR before loading the MLID or
unload the TSR before trying this operation.
FATAL: This old LSL is not supported.
Source: IPXODI
Explanation: IPXODI cannot run correctly using this version of
the LSL.
Action: Update your LSL.COM to a newer version.
or
Source: MLID
Explanation: The MLID cannot run correctly using this version
of the LSL.
Action: Update your LSL.COM to a newer version.
FATAL: Work Area Exceeded, reduce number of SAPs and/or Link
Stations.
Source: LANSUP.COM
Explanation: The number of SAPs or Link Stations specified in
the NET.CFG file exceeded the maximum number of SAPs or
Link Stations that the network board can handle.
Action: Modify the number of SAPs or Link Stations specified
in the NET.CFG file.
IPX protocol bound to <name> MLID Board # <number>.
Source: IPXODI
Explanation: This message is displayed after IPX has successfully
loaded. It is not a error message but simply tells you which
logical MLID IPX is using.
<name> The MLID's short name (NE1000, for example).
<number> The logical board number of the MLID. This
number is 1 based (for example, the first MLID is
assigned board #1).
Action: None.
IPX protocol successfully removed.
Source: IPXODI
Explanation: A request was made to unload IPXODI, and
IPXODI was removed (unloaded) from memory.
Action: None.
LSL successfully removed.
Source: LSL
Explanation: A request was made to unload the LSL, and the LSL
was removed from memory.
Action: None.
Number of buffers <number1>, Buffer size <size> bytes, Memory pool
<number2> bytes
Source: LSL
Explanation: This information appears when the LSL has read
configuration information from the NET.CFG file. (LSL does not
display default values when it loads.)
<number1> The number of communication buffers
allocated by the LSL. Normally, the LSL
does not need buffers; therefore, none
should be allocated unless directed by a
protocol's documentation. This number may
be less than requested due to memory limits
within the LSL.
<size> The size of the LSL's communications
buffers (106 bytes of this value are reserved
for protocol and media headers). This value
cannot be smaller than 618 bytes.
<number2> The amount of memory allocated to the
LSL's free memory pool. This free memory
pool is used by protocols. This value may be
smaller than requested due to memory limits
within the LSL. The LSL first allocates the
requested number of communications
buffers and then allocates the free memory
pool from the remaining memory. Normally,
a free memory pool is not needed and should
not be allocated, unless directed by a
protocol's documentation.
Action: None.
<name> MLID successfully removed.
Source: MLID
Explanation: A request was made to unload an MLID, and the
MLID was removed from memory.
Action: None.
WARNING: Byte value greater than 255 was truncated
Source: IPXODI
Explanation: An IPX or SPX parameter specified in the
NET.CFG or SHELL.CFG file was set to a value greater than 255.
The value used will be 255 (the maximum configurable value).
Action: Change the NET.CFG file so that the IPX or SPX
parameter has a valid value.
WARNING: Error registering Protocol=<name>, PID=<number>,
Frame=<type>
Source: MLID
Explanation: The MLID could not register the specified Protocol
ID.
<name> The name of the protocol.
<number> The value of the Protocol ID used to register the
Protocol ID.
<type> The frame type for which the Protocol ID was
registered.
Action: Verify the protocol information in the NET.CFG file.
WARNING: Invalid LOOK AHEAD SIZE value, will be set to maximum
(128 bytes).
Source: MLID
Explanation: The ■LOOK AHEAD SIZE■ option was specified
in the NET.CFG for an MLID. The value specified was greater
than 128 bytes. The MLID will use 128 bytes for its look ahead
size.
Action: Change the ■LOOK AHEAD SIZE■ option in the
NET.CFG file to a valid value.
WARNING: MLID does not support Frame <type> - Protocol keyword
ignored.
Source: MLID
Explanation: The ■PROTOCOL■ option was specified in the
NET.CFG for an MLID. The specified frame type is not
supported by the MLID.
Action: Check the ■PROTOCOL■ line in the NET.CFG file for
possible omissions of required dashes and underscores or any
misspellings. Check the MLID documentation for supported
frame types.
WARNING: NET.CFG ignored - file length must be less than 4097 bytes.
Source: IPXODI
Explanation: The NET.CFG file is larger than 4,096 bytes. IPX
still loads, but ignores the information in the NET.CFG file.
Action: Reduce the size of the NET.CFG file.
or
Source: LSL
Explanation: The NET.CFG file is larger than 4,096 bytes. The
LSL still loads, but ignores the information in the NET.CFG file.
Action: Reduce the size of the NET.CFG file.
or
Source: MLID
Explanation: The NET.CFG file is longer than 4,096 bytes. The
MLID still loads, but ignores the information in the NET.CFG
file.
Action: Reduce the size of the NET.CFG file.
WARNING: NET.CFG ignored - MLID name cannot be more than 8
characters long.
Source: IPXODI
Explanation: The ■Bind MLID■ option in the NET.CFG file
specified an MLID with a name longer than 8 characters.
Action: Refer to the MLID's documentation for more information
on the name.
WARNING: Node Address override not supported. Specify override when
loading IBM LAN Support Software.
Source: LANSUP.COM
Explanation: A node address was specified in the NET.CFG file
for the LANSUP.COM driver. The node override must be
specified when loading the IBM LAN Support software.
Action: Refer to the IBM LAN Support documentation for
instructions.
WARNING: No room in the LSL for another board. Board <number> will
not be activated.
Source: MLID
Explanation: The maximum number of boards has been
registered with the Link Support Layer. The DOS ODI LSL can
support up to eight boards.
Action: Reduce the number of active boards in the system by
unloading a board.
WARNING: Protocol keyword must have a frame type - entry ignored.
Source: MLID
Explanation: The ■PROTOCOL■ option was specified in the
NET.CFG for an MLID. The entry failed to specify the
associated frame type for the protocol ID addition. An entry in
the NET.CFG file for the ■PROTOCOL■ option would look
similar to the following:
LINK DRIVER NE1000
PROTOCOL IPX 8137 ETHERNET_II
Action: Specify a frame type with the ■PROTOCOL■ option.
WARNING: Specified MAX PACKET SIZE too big for this adapter, max
size used.
Source: LANSUP.COM
Explanation: The specified maximum packet size in the
NET.CFG file was too large for the network board installed in
the workstation. The maximum packet size for the network board
was used.
Action: Modify the maximum packet size in the NET.CFG file.
Notes
Trademarks
Novell, Inc., has made every effort to supply trademark information
about company names, products, and services mentioned in this book.
Trademarks indicated below were derived from various sources.
3Com, 3Com EtherLink, and EtherLink Plus are trademarks of 3Com
Corporation.
AppleTalk is a registered trademark of Apple Computer, Inc.
IBM is a registered trademark of International Business MachinesCorporation.
IBM PC AT/XT are trademarks of International Business MachinesCorporation.
IBM Personal System/2 is a registered trademark of InternationalBusiness Machines Corporation.
Internetwork Packet Exchange (IPX) is a trademark of Novell, Inc.
Micro Channel is a trademark of International Business Machines
Corporation.
MS-DOS is a trademark of Microsoft Corporation.
NetWare and Novell are registered trademarks of Novell, Inc.
NetWire is a trademark of Novell, Inc.
Novell RX-Net is a trademark of Novell, Inc.
OS/2 is a registered trademark of International Business Machines
Corporation.
PC-DOS is a trademark of International Business Machines
Corporation.
Personal Computer AT and Personal Computer XT are trademarksof International Business Machines Corporation.
Personal System/2 is a trademark of International BusinessMachines Corporation.
Token-Ring is a trademark of International Business Machines
Corporation.
Notes
Index
A
AUTOEXEC.BAT
copying to workstation boot diskettes 11
creating for master workstationdiskette 9
B
BIND (NET.CFG) 21
Boot disk, workstation
booting with 10, 12
creating master 7
creating users' diskettes 11
BUFFERS (NET.CFG) 20
Communication buffers 20
C
Computers, workstation requirements 4
CONFIG.SYS 10
D
DEFAULT (NET.CFG) 22
DMA (NET.CFG) 23
Drivers. See also LAN drivers
accessing information about 13
unloading ODI 14
E
EMSNETx.EXE, expanded memory shell file 8
Expanded memory shell 8
Extended memory shell 8
F
File server, logging in to 12
FRAME (NET.CFG) 28
H
Hardware, workstations supported 4
I
IBM Token-Ring Source Routing Driver 31
using with DOS ODI 33
INT (NET.CFG) 24
INT2F.COM file on master workstation diskette 9
IPXODI
copying to master workstation diskette 9
explained 2
removing parts of 13
L
LAN drivers
accessing information about 13
supporting multiple protocols 1
unloading workstation ODI 14
LANSUP.COM driver 9, 30
Link driver LANSUP options 30
Link driver options in NET.CFG 23
LINK STATIONS (NET.CFG) 30
Link support options (NET.CFG) 20
LOOK AHEAD SIZE (NET.CFG) 28
LSL.COM file on master workstation diskette 8
M
MEM (NET.CFG) 25
Memory requirements
workstation 4
Memory settings for NET.CFG 25
MEMPOOL (NET.CFG) 21
N
NET.CFG
conventions 18
creating 10, 17
example 18
options 19
using with SHELL.CFG 17
NETBIOS.EXE
adding to master workstation diskette 9
Network boards
installing in workstations 5
interrupt settings in NET.CFG 24
NETx.COM adding to master workstation diskette 8
NODE ADDRESS (NET.CFG) 26
P
PORT (NET.CFG) 26
PRESCAN (NET.CFG) 22
Protocol
options in NET.CFG 29
using multiple on a workstation 1
PS/2 SLOT (NET.CFG) 27
PS/2 SLOT ? (NET.CFG) 27
R
RAM, workstation memory requirements 4
ROUTE.COM 9
setting parameters for 34
Routing, source. See IBM Token-Ring Source Routing Driver
S
SAPS (NET.CFG) 30
SEND RETRIES (NET.CFG) 29
SESSIONS (NET.CFG) 22
SHELL.CFG, using with NET.CFG 17
Source routing. See IBM Token-Ring Source Routing Driver
T
Troubleshooting, workstation installation 13
W
Workstation
booting 12
hardware requirements 4
installing (DOS ODI) 3
memory requirements 4
troubleshooting 13
X
XMSNETx.EXE, extended memory shell file 8